When doing a bootstrap, we use a newly built clang.
When this one is used, if already installed on the system,
we have clang header in two places:
llvm-toolchain-7-7/build-llvm/lib/clang/7.0.0/include/inttypes.h
and
/usr/include/clang/7.0.0/include/inttypes.h
Because clang expects only one of his headers to be available, it uses
include_next to get the glibc (libc6-dev package) header.
However, in the previous example, because we have inttypes.h twice in the
include search path, clang's header will call itself without any effect.
Therefore, it will do include_next until the define from the libc is existing (ex: _INTTYPES_H)
The MIPS port aims to support the Loongson 3 family of CPUs in addition
of the other MIPS CPUs. On the Loongson 3 family the MADD4 instructions
are fused, while they are not fused on the other MIPS CPUs. In order to
support both, we have to disabled those instructions.
For that, the patch below basically corresponds to the --with-madd4=no
used on the GCC side.
Clang 3.9 regression causes a bug when generating code for
std::atomic_compare_and_exchange*(std::atomic<long long>,...) without
optimizations. If same code is compiled with -O2 tests pass without problems.
Atomics are implement in headers with builtin functions which makes this
affect application code instead of libc++ library code.
libcxx tests default to -O0 compilation so these test need to be marked failing
on arm to allow installing packages. Use cases is so borderline failure that it
shouldn't prevent building the package. (64bit atomics in 32bit mode)
Gbp-Pq: Topic libcxx
Gbp-Pq: Name libcxx-test-atomics-set-compare-exchange-to-be-expected-fails-on-arm.patch
Fix arm EHABI code to work. armhf had exception test failing without EHABI support.
No known upstream bug about this. Actual code change is more like workaround than
something that upstream would accept. Proper fix would be adding _Unwind_Control_Block
to clang unwind.h. _Unwind_Control_Block should also extend _Unwind_Exception to make
sure their ABI stays in sync.
No known upstream bug about this.
Gbp-Pq: Topic libcxx
Gbp-Pq: Name libcxxabi-arm-ehabi-fix.patch
Lock is_always_lock free test fails on i386 because std::atomic is aligned
Lock is_always_lock free test fails on i386 because std::atomic is aligned
to 8 bytes while long long is aligned to 4 bytes. clang can't generate inline
code for unaligned 8 byte atomics even tough instruction set and gcc support
it.
That makes it expected thaqt ATOMIC_LLONG_LOCK_FREE and
std::atomic<long long>::is_always_lock_free don't match on i386. Correct test
for std::atomic<long long> is to check if target cpu support cmpxchg8 instruction.
To set instruction support one can check __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 define.
Bug: https://llvm.org/bugs/show_bug.cgi?id=19355
Gbp-Pq: Topic libcxx
Gbp-Pq: Name libcxx-test-fix-lockfree-test-for-i386.patch
Powerpc has extended double that doesn't match x86 coding. Power format would
need special tests to verify correctness but for now it is enough to prevent
incorrect test from running.
Gbp-Pq: Topic libcxx
Gbp-Pq: Name libcxxabi-test-don-t-fail-extended-long-double.patch
lldb-server exec users always /usr/bin/lldb-server. Server is required
for any debugging with lldb which makes it unusable unless default version
package has been installed. Small changes to code and debian/rules allows
a workaround for lldb-server start up.
To use this one needs to add cmake definition during configure. eg
-DDEBIAN_VERSION_SUFFIX=-$(LLVM_VERSION)
Better implementation would be to use /usr/share/llvm-$(VERSION)/bin but
that change seems to require a big change to the path handling code
which could then break something else.
This probably should have upstream bug but I couldn't find any existing report.
Gbp-Pq: Topic lldb
Gbp-Pq: Name lldb-addversion-suffix-to-llvm-server-exec.patch
Sylvestre [Wed, 6 Jan 2021 19:16:26 +0000 (19:16 +0000)]
Silent a test failing on yakkety amd64
Last-Update: 2016-08-26
/tmp/buildd/llvm-toolchain-snapshot-4.0~svn279801/llvm/test/tools/llvm-symbolizer/print_context.c:16:11: error: expected string not found in input
// CHECK: inc
^
<stdin>:1:1: note: scanning from here
_fini
^
<stdin>:1:3: note: possible intended match here
_fini
^
Command Output (stderr):
--
/build/llvm-toolchain-snapshot-4.0~svn279916/llvm/test/tools/gold/X86/start-lib-common.ll:22:10: error: expected string not found in input
; CHECK: @x = common global i32 0, align 8
^
<stdin>:1:1: note: scanning from here
; ModuleID = '/build/llvm-toolchain-snapshot-4.0~svn279916/build-llvm/llvm/test/tools/gold/X86/Output/start-lib-common.ll.tmp3.o'
^
<stdin>:4:1: note: possible intended match here
@x = common global i32 0, align 4
^
Peter Wu [Fri, 4 May 2018 13:43:06 +0000 (15:43 +0200)]
[PATCH] [llvm] cmake: resolve symlinks in LLVMConfig.cmake
Ensure that symlinks such as /usr/lib/llvm-X.Y/cmake (pointing to
lib/cmake/llvm) are resolved. This ensures that LLVM_INSTALL_PREFIX
becomes /usr/lib/llvm-X.Y instead of /usr.
Partially addresses PR37128
Gbp-Pq: Name 0001-llvm-cmake-resolve-symlinks-in-LLVMConfig.cmake.patch
Peter Wu [Fri, 4 May 2018 13:55:26 +0000 (15:55 +0200)]
[PATCH] [clang] cmake: resolve symlinks in ClangConfig.cmake
Ensure that symlinks such as /usr/lib/cmake/clang-X.Y (pointing to
/usr/lib/llvm-X.Y/lib/cmake/llvm) are resolved. This ensures that
CLANG_INSTALL_PREFIX ends up to be /usr/lib/llvm-X.Y instead of /usr.
Partially addresses PR37128
Gbp-Pq: Name 0001-tools-clang-cmake-resolve-symlinks-in-ClangConfig.cmake.patch
# Without this patch, the first local include of unwind.h might, with the
# __has_include_next, try to include the one from the system.
# It might be /usr/include/clang/3.4/include/unwind.h
# Because of the #ifndef __CLANG_UNWIND_H, it might never include any declaration
# from the system.
When doing a bootstrap, we use a newly built clang.
When this one is used, if already installed on the system,
we have clang header in two places:
llvm-toolchain-7-7/build-llvm/lib/clang/7.0.0/include/inttypes.h
and
/usr/include/clang/7.0.0/include/inttypes.h
Because clang expects only one of his headers to be available, it uses
include_next to get the glibc (libc6-dev package) header.
However, in the previous example, because we have inttypes.h twice in the
include search path, clang's header will call itself without any effect.
Therefore, it will do include_next until the define from the libc is existing (ex: _INTTYPES_H)
The MIPS port aims to support the Loongson 3 family of CPUs in addition
of the other MIPS CPUs. On the Loongson 3 family the MADD4 instructions
are fused, while they are not fused on the other MIPS CPUs. In order to
support both, we have to disabled those instructions.
For that, the patch below basically corresponds to the --with-madd4=no
used on the GCC side.
projects / llvm-toolchain-11.git / log